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DETAILED ACTION 

1 . This office action is responsive to communications filed on 1 0/1 2/2007. 
Claims 1-14 are pending and have been examined. 



Double Patenting 

2. The nonstatutory double patenting rejection is based on a judicially created 
doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the 
unjustified or improper timewise extension of the "right to exclude" granted by a patent 
and to prevent possible harassment by multiple assignees. A nonstatutory 
obviousness-type double patenting rejection is appropriate where the conflicting claims 
are not identical, but at least one examined application claim is not patentably distinct 
from the reference claim(s) because the examined application claim is either anticipated 
by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 
F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 
USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 
1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 
F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 
USPQ 644 (CCPA 1969). 

A timely filed terminal disclaimer in compliance with 37 CFR 1 .321 (c) or 1 .321 (d) 
may be used to overcome an actual or provisional rejection based on a nonstatutory 
double patenting ground provided the conflicting application or patent either is shown to 
be commonly owned with this application, or claims an invention made as a result of 
activities undertaken within the scope of a joint research agreement. 

Effective January 1 , 1994, a registered attorney or agent of record may sign a 
terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 
37 CFR 3.73(b). 

Claims 1-14 are provisionally rejected on the ground of nonstatutory 
obviousness-type double patenting as being unpatentable over claims of copending 
Application No. 10/733,055. Although the conflicting claims are not identical, they are 
not patentably distinct from each other because the inference engine disclosed in the 
present application is performing the same function as in utilizing the real-time 
connectivity information from client's systems to establish a network connection to a 
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computer network. And although, one is a method claim, the other is a computer 
readable medium claim, it would be have been obvious to one of ordinary skill in the art 
at the time of invention was to made to implement the method claim in a computer 
readable medium. Therefore, it is sufficiently to conclude that the present application is 
an obvious variation of application: 10/733,055. 



This is a provisional obviousness-type double patenting rejection because the 
conflicting claims have not in fact been patented. 



Claims of present application 


Claims of application: 10/733,055 


1. A method for re-establishing a network 


Claim 1. A computer readable medium 


connection for a client computer system 


containing program instructions for 


after a failed network connection, said 


establishing a connection between a client 


iiiciiiuu iaji i ipi ibii iy . 


oyoiciii diiu a iitHwuift, uic piuyidiii 


collecting real-time connectivity 


instructions for: 


information by said client computer 


(a) collecting real time connectivity 


system; 


information by the client system, wherein 


storing said real-time connectivity 


the collecting instruction (a) further 


information in a local persistent 


includes: 


knowledgebase within said client 


(al)monitoring and collecting network 


computer system; 


traffic in real time; 


utilizing said real-time connectivity 


(a2)assigning a weight to the real time 


information by said client computer system 


network traffic based on popularity; and 


to establish a network connection with a 


(a3)creating a weighted list from the 
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computer network; 


weighted real time network traffic; and 


determining whether or not a 


(b) utilizing the real time connectivity 


connection failure occurred at said 


information by the client system to 


network connection; 


establish a connection with the network. 


in a determination that a failure 


Claim 8. The computer readable medium 


occurred at said network connection, 


of claim 1, wherein the utilizing instruction 


invoking an inference engine to utilize said 


(b) includes: 


real-time connectivity information in said 


(b1) detecting a failed connection; 


local persistent knowledgebase to re- 


(b2) determining a cause of the failed 


establish a network connection to said 


connection by the client system; 


computer network. 


(b3) generating a solution based on the 


2. The method of claim 1 , wherein said 


cause and the real time connectivity 


method further includes invoking a verify 


information; and 


function by said inference engine to 


(b4) implementing the solution. 


determine status of each communication 


Claims 2. The computer readable medium 


device within said client computer system. 


of claim 1 further comprising: 


3. The method of claim 2, wherein said 


(c) utilizing data from a local persistent 


method further includes determining a root 


knowledgebase to establish a connection 


cause of said connection failure by said 


to 


inference engine based on status of each 


the network 


communication device. 


Claim 4. Canceled 


4. The method of claim 3, wherein said 


Claim 5. The computer readable medium 
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method further includes generating a best 


of claim 4 further comprising the instruction 


solution by said inference engine for re- 


for: 


establishing said network connection 


(c) storing the weighted list in the client 


based on said root cause of said 


system. 


connection failure. 




5. The method of claim 1 , wherein said 




collecting real-time connectivity 




information further includes 




monitoring and collecting network 




traffic of said client computer system in 




real time; and 




generating a weighted list of 




network traffic having address utilization 




listed in a descending order. 




This applies substantially the same to 
claims 8-14 





3. The nonstatutory double patenting rejection is based on a judicially created 
doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the 
unjustified or improper timewise extension of the "right to exclude" granted by a patent 
and to prevent possible harassment by multiple assignees. A nonstatutory 
obviousness-type double patenting rejection is appropriate where the conflicting claims 
are not identical, but at least one examined application claim is not patentably distinct 
from the reference claim(s) because the examined application claim is either anticipated 
by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 
F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 
USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 
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1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 
F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 
USPQ 644 (CCPA 1969). 

A timely filed terminal disclaimer in compliance with 37 CFR 1 .321 (c) or 1 .321 (d) 
may be used to overcome an actual or provisional rejection based on a nonstatutory 
double patenting ground provided the conflicting application or patent either is shown to 
be commonly owned with this application, or claims an invention made as a result of 
activities undertaken within the scope of a joint research agreement. 

Effective January 1 , 1994, a registered attorney or agent of record may sign a 
terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 
37 CFR 3.73(b). 

4. Claims 1-14 are rejected on the ground of nonstatutory obviousness-type double 
patenting as being unpatentable over claims of U.S. Patent No. 7,181,653. Although 
the conflicting claims are not identical, they are not patentably distinct from each other 
because the inference engine disclosed in the present application is performing the 
same function as in utilizing the real-time connectivity information from client's systems 
to establish a network connection to a computer network. Therefore, it is sufficiently to 



conclude that the present application is an obvious variation of Patent no.: 7,181,653. 



Claims of present application 


Claims of USPN: 7,181,653 


1. A method for re-establishing a network 
connection for a client computer system 
after a failed network connection, said 
method comprising: 

collecting real-time connectivity 
information by said client computer 
system; 

storing said real-time connectivity 


Claim 1. A method for establishing a 
network connection between a client 
system and a network comprising: 
(a) collecting real time connectivity 
information by the client system, wherein 
collecting real time connectivity 
information includes 
(a1) monitoring and collecting network 
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information in a local persistent 


traffic in real time through an adapter not 


knowledgebase within said client 


yet enabled to communicate with the 


computer system; 


network wherein the network traffic 


utilizing said real-time connectivity 


comprises addresses recently assigned 


information by said client computer system 


by a DHCP server and addresses and 


to establish a network connection with a 


names of SOCKS servers; 


computer network; 


(a2) assigning a weight to the real time 


determining whether or not a 


network 


connection failure occurred at said 


traffic based on utilization; 


network connection; 


(a3) creating a weighted list from the 


in a determination that a failure 


weighted 


occurred at said network connection, 


real time network traffic; 


invoking an inference engine to utilize said 


(b) utilizing the real time connectivity 


real-time connectivity information in said 


information collected by the client system 


local persistent knowledgebase to re- 


and data from a local persistent 


establish a network connection to said 


knowledgebase to establish a connection 


computer network. 


with the network by 


2. The method of claim 1 , wherein said 


(b1) detecting a failed connection; 


method further includes invoking a verify 


(b2) determining a cause of the failed 


function by said inference engine to 


connection by the client system by 


determine status of each communication 


analyzing at least one more message 


device within said client computer system. 


associated with the failed connection and 
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3. The method of claim 2, wherein said 


auditing a plurality of communication 


method further includes determining a root 


devices in the client to determine which of 


cause of said connection failure by said 


the plurality of communication devices is a 


inference engine based on status of each 


potential candidate for connectivity; 


communication device. 


(b3) generating a solution based on the 


4. The method of claim 3, wherein said 


cause and the real time connectivity 


method further includes generating a best 


information; and 


solution by said inference engine for re- 


(b4) implementing the solution. 


establishing said network connection 


Claim 2. The method of claim 1 further 


based on said root cause of said 


comprising: (c) utilizing data from a local 


connection failure. 


persistent knowledgebase to establish a 


5. The method of claim 1 , wherein said 


connection to the network. 


collecting real-time connectivity 


Claim 3. The method of claim 1 further 


information further includes 


comprising: (c) utilizing data from a server 


monitoring and collecting network 


based database to establish a connection 


traffic of said client computer system in 


to the network. 


real time; and 


Claim 4. The method of claim 1 , wherein 


generating a weighted list of 


the collecting step (a) further includes: (a1) 


network traffic having address utilization 


monitoring and collecting network traffic in 


listed in a descending order. 


real time; (a2) assigning a weight to the 




real time network traffic based on 




popularity; and (a3) creating a weighted list 
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from the weighted real time network traffic. 


This applies substantially the same to 
claims 8-14 





Claim Rejections - 35 USC § 102 

5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1 ) an application for patent, published under section 1 22(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

6. Claims 1-4, 6, 8-11 and 13 are rejected under 35 U.S.C. 102(e) as being 
anticipated by Miller (Patent no.: US 6,742,141 B1). 

With respect to claim 1, Miller teaches a method for re-establishing a network 
connection for a client computer system after a failed network connection, said method 
comprising: 

collecting real-time connectivity information by said client computer system 
(Miller: fig. 5, col. 9, lines 53-64), 

storing said real-time connectivity information in a local persistent 
knowledgebase within said client computer system (Miller: fig. 5, col. 9, lines 20-64, 
noted the customer knowledge base); 
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utilizing said real-time connectivity information by said client computer system to 
establish a network connection with a computer network (Miller: col. 9, lines 62-64 and 
col. 11, lines 2-14); 

determining whether or not a connection failure occurred at said network 
connection (Miller: fig. 1 1 & 12, col. 14, lines 42-67, noted the symptom includes the 
internet problem, which inherently has the connection problem). 

in a determination that a failure occurred at said network connection, invoking an 
inference engine to utilize said real-time connectivity information in said local persistent 
knowledgebase to re-establish a network connection to said computer network (Miller: 
fig. 7, col. 10 line 59 to col. 11 line 21). 

With respect to claim 2, Miller teaches the method of claim 1 , wherein said 
method further includes invoking a verify function by said inference engine to determine 
status of each communication device within said client computer system (Miller, col. 14, 
lines 9-41). 

With respect to claim 3, Miller teaches the method of claim 2, wherein said 
method further includes determining a root cause of said connection failure by said 
inference engine based on status of each communication device (Miller: fig. 10 and col. 
13, lines 39-61). 

With respect to claim 4, Miller teaches the method of claim 3, wherein said 
method further includes generating a best solution by said inference engine for re- 
establishing said network connection based on said root cause of said connection 
failure (Miller, fig. 10, col. 13, lines 39-61, noted executing the solution). 
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With respect to claim 6, Miller teaches the method of claim 1 , wherein said 
method further includes 

analyzing at least one error message associated with failed network connection 
(Miller, fig. 8B and col. 14. lines 7-14); and 

auditing a plurality of communication devices to determine which of said plurality 
of communication devices is a potential candidate for connectivity (Miller, col. 14, lines 
9-41). 

In regard to claims 8-11 and 13, the limitations of these claims are substantially 
the same as those in claims 1-4 and 6, but rather in a computer instruction stored on a 
computer readable medium form. Therefore the same rationale for rejecting claims 1-4 
and 6 is used to reject claims 8-1 1 and 13. By this rationale claims 8-11 and 13 are 
rejected. 

Claim Rejections - 35 USC § 103 

7. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this 
title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a 
whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said 
subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made. 

8. Claims 5 and 12 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Miller (Patent no.: US 6,742,141 B1) in view of Kramer et al. (Patent no.: US 
7,096,210 B1). 
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With respect to claim 5, Miller teaches the method of claim 1 , wherein said 
collecting real-time connectivity information further includes 

monitoring and collecting network traffic of said client computer system in real 
time (Miller, col. 9, lines 53-64); and 

generating a weight to network traffic having address utilization (Miller, col. 10, 
lines 35-45, noted that from the data collected the severity level of network connectivity 
problem is assigned). 

Miller also teaches a method of providing list for customer knowledge base 
(Miller, fig. 6). However, Miller fails to teach a method of providing a severity list of the 
problem collected. 

In the same field of endeavor, Kramer teaches a method of providing a severity 
list of the problem collected (Kramer, col. 27, lines 31-34). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to incorporate the method of providing a severity list of the 
problem collected as taught by Kramer in Miller's invention of the customer's 
knowledgebase with the advantage being that it would be easier to identify how serious 
the problem is and effectively execute the best solution to the problem. 

In regard to claim 12, the limitations of this claim are substantially the same as 
those in claim 5. Therefore the same rationale for rejecting claim 5 is used to reject 
claim 12. By this rationale claim 12 is rejected. 
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9. Claims 7 and 14 are and are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Miller (Patent no.: US 6,742,141 B1) in view of Farrow et al. 
(Patent no.: US 6,374,295 B2). 

With respect to claim 7, Miller teaches all the claimed limitations except that he 
does not explicitly teach a method of analyzing real time connectivity information to 
determine a range of IP addresses assigned by a DHCP server; generating a plurality of 
IP addresses within said range of IP addresses; and selecting and assigning one of said 
plurality of IP addresses to said client computer system if said one IP address is not in 
use. 

In the same field of endeavor, Farrow teaches a method analyzing real time 
connectivity information to determine a range of IP addresses assigned by a DHCP 
server (Farrow, col. 1 lines 29-32); generating a plurality of IP addresses within said 
range of IP addresses (Farrow, col. 1 lines 25-44); and selecting and assigning one of 
said plurality of IP addresses to said client computer system if said one IP address is 
not in use (Farrow, col. 1 lines 25-44). 

Therefore, it would have been obvious to one of ordinary skill in this art at the 
time of invention by applicant to implement Miller's method for generating a 
solution with Farrow's method of assigning IP addresses to client systems. A person of 
ordinary skill in this art would have been motivated to make the modification because 
DHCP simplifies management by eliminate the need for the network administrator to 
manually configure the network (Farrow: column 1 , lines 26-29). 
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In regard to claim 14, the limitations of this claim are substantially the same as 
those in claim 7. Therefore the same rationale for rejecting claim 7 is used to reject 
claim 14. By this rationale claim 14 is rejected. 

10. Claims 1-4, 6, 8-11 and 13 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Miller (Patent no.: US 6,742,141 B1) in view of Wall et al. (PGPUB 
No.: US 2003/0142633 A1). 

With respect to claim 1, Miller teaches a method for re-establishing a network 
connection for a client computer system after a failed network connection, said method 
comprising: 

collecting real-time connectivity information by said client computer system 
(Miller: fig. 5, col. 9, lines 53-64), 

storing said real-time connectivity information in a local persistent 
knowledgebase within said client computer system (Miller: fig. 5, col. 9, lines 20-64, 
noted the customer knowledge base); 

utilizing said real-time connectivity information by said client computer system to 
establish a network connection with a computer network (Miller: col. 9, lines 62-64 and 
col. 11, lines 2-14). 

determining internet symptom (Miller: fig. 11 & 12, col. 14, lines 42-67). 

in a determination of internet symptom, invoking an inference engine to utilize 
said real-time connectivity information in said local persistent knowledgebase to re- 
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establish a network connection to said computer network (Miller: fig. 7, col. 10 line 59 to 
col. 11 line 21). 

However, Miller does not explicitly disclose a method of determining whether or 
not a connection failure occurred at network connection. 

In the same field of endeavor, Wall teaches a method of determining whether or 
not a connection failure occurred at network connection (Wall: page 5, paragraph 46). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to incorporate the method of determining the network 
connection as taught by Wall in Miller's invention in order to create a list tasks to be 
fixed by the technician (Wall: page 5, paragraph 47). 

With respect to claim 2, Miller teaches the method of claim 1 , wherein said 
method further includes invoking a verify function by said inference engine to determine 
status of each communication device within said client computer system (Miller, col. 14, 
lines 9-41). 

With respect to claim 3, Miller teaches the method of claim 2, wherein said 
method further includes determining a root cause of said connection failure by said 
inference engine based on status of each communication device (Miller: fig. 10 and col. 
13, lines 39-61). 

With respect to claim 4, Miller teaches the method of claim 3, wherein said 
method further includes generating a best solution by said inference engine for re- 
establishing said network connection based on said root cause of said connection 
failure (Miller, fig. 10, col. 13, lines 39-61, noted executing the solution). 
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With respect to claim 6, Miller teaches the method of claim 1 , wherein said 
method further includes 

analyzing at least one error message associated with failed network connection 
(Miller, fig. 8B and col. 14. lines 7-14); and 

auditing a plurality of communication devices to determine which of said plurality 
of communication devices is a potential candidate for connectivity (Miller, col. 14, lines 
9-41). 

In regard to claims 8-11 and 13, the limitations of these claims are substantially 
the same as those in claims 1-4 and 6, but rather in a computer instruction stored on a 
computer readable medium form. Therefore the same rationale for rejecting claims 1-4 
and 6 is used to reject claims 8-1 1 and 13. By this rationale claims 8-11 and 13 are 
rejected. 

1 1 . Claims 5 and 12 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Miller (Patent no.: US 6,742,141 B1) in view of Wall et al. (PGPUB No.: US 
2003/0142633 A1) and further in view of Kramer et al. (Patent no.: US 7,096,210 B1). 

With respect to claim 5, Miller teaches the method of claim 1 , wherein said 
collecting real-time connectivity information further includes 

monitoring and collecting network traffic of said client computer system in real 
time (Miller, col. 9, lines 53-64); and 

generating a weight to network traffic having address utilization (Miller, col. 10, 
lines 35-45, noted that from the data collected the severity level of network connectivity 
problem is assigned). 
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Miller also teaches a method of providing list for customer knowledge base 
(Miller, fig. 6). However, the combined method of Miller and Wall fails to teach a method 
of providing a severity list of the problem collected. 

In the same field of endeavor, Kramer teaches a method of providing a severity 
list of the problem collected (Kramer, col. 27, lines 31-34). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to incorporate the method of providing a severity list of the 
problem collected as taught by Kramer in the combined method of Miller's and wall's 
invention of the customer's knowledgebase with the advantage being that it would be 
easier to identify how serious the problem is and effectively execute the best solution to 
the problem. 

In regard to claim 12, the limitations of this claim are substantially the same as 
those in claim 5. Therefore the same rationale for rejecting claim 5 is used to reject 
claim 12. By this rationale claim 12 is rejected. 

12. Claims 7 and 14 are and are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Miller (Patent no.: US 6,742,141 B1) in view of Wall et al. (PGPUB 
No.: US 2003/0142633 A1) and further in view of Farrow et al. (Patent no.: US 
6,374,295 B2). 

With respect to claim 7, the combined method of Miller and Wall teaches all the 
claimed limitations except that he does not explicitly teach a method of analyzing real 
time connectivity information to determine a range of IP addresses assigned by a DHCP 
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server; generating a plurality of IP addresses within said range of IP addresses; and 
selecting and assigning one of said plurality of IP addresses to said client computer 
system if said one IP address is not in use. 

In the same field of endeavor, Farrow teaches a method analyzing real time 
connectivity information to determine a range of IP addresses assigned by a DHCP 
server (Farrow, col. 1 lines 29-32); generating a plurality of IP addresses within said 
range of IP addresses (Farrow, col. 1 lines 25-44); and selecting and assigning one of 
said plurality of IP addresses to said client computer system if said one IP address is 
not in use (Farrow, col. 1 lines 25-44). 

Therefore, it would have been obvious to one of ordinary skill in this art at the 
time of invention by applicant to implement the combined method of Miller's and Wall's 
method for generating a solution with Farrow's method of assigning IP addresses to 
client systems. A person of ordinary skill in this art would have been motivated to make 
the modification because DHCP simplifies management by eliminate the need for the 
network administrator to manually configure the network (Farrow: column 1, lines 26- 
29). 

In regard to claim 14, the limitations of this claim are substantially the same as 
those in claim 7. Therefore the same rationale for rejecting claim 7 is used to reject 
claim 14. By this rationale claim 14 is rejected. 
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Response to Arguments 

1 3. Applicant's arguments with respect to claims 1 -1 4 have been considered but are 
moot in view of the new ground(s) of rejection. 

Conclusion 

14. Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 

§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

1 5. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Lin Liu whose telephone number is (571) 270-1447. 
The examiner can normally be reached on Monday - Friday, 7:30am - 5:00pm, EST. 



Application/Control Number: 10/733,591 Page 20 

Art Unit: 2145 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Jason Cardone can be reached on (571) 272-3933. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/L U 
/Lin Liu/ 

Examiner, Art Unit 2145 



/Jason D Cardone/ 
Supervisory Patent Examiner, Art Unit 2145 



